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ABSTRACT 


The cyclomatic complexity metric provides a means of quantifying intra-modular 

software complexity, and its utility has been suggested in the software development and 

^ • 

' t . ■- 

\ 

testing process. In this study, an empirical analysis was undertaken to examine the 
relationship between the cyclomatic complexity and the incidence of faults in a series of 
eight relatively large (from 1200 to 2400 LOC) complex programs. Each of these 
programs was developed from a single program specification and subsequently subjected 
to rigorous unit level testing. A comparison was also made between the relationship of 
cyclomatic complexity to faults and the relationship of Lines of Code (LOC) to faults. 

The results of this study support a relationship between the cyclomatic complexity 
and the incidence of faults. Further, a relationship between LOC and faults is 
demonstrated. It could not be shown that there exists a stronger relationship between 
cyclomatic complexity and faults than LOC and faults. 


\- 


iii 







TABLE or COMTDITS 


I. INTRODUCTION . 1 

A. IMPORTANCE OF SOFTWARE TESTING . 1 

B. APPROACH . 4 

1. Definition of Cyclomatic Complexity .... 4 

2. Cyclomatic Complexity Measure and Lines of 

Code. 6 

3. Use of An Experiment to Evaluate the 

Cyclomatic Complexity . 7 

C. PROBLEM STATEMENT . 12 

D. OVERVIEW OF THE THESIS . 13 

II. DESCRIPTION OF EXPERIMENT AND RESULTS . 14 

A. INTRODUCTION . 14 

B. EXPERIMENTAL METHODOLOGY . 14 

1. TOOL FOR COMPUTING V(G) . 14 

C. EXPERIMENTAL DATA BASE . 16 

D. RESULTS. 19 

1. Relationship of V (G) to Faults. 19 

2. Relationship of Cyclomatic Complexity to Lines 

of Code. >0 

3. Summary of Results. 4 8 


IV 





















III. SUMMARY AND CONCLUSIONS. 50 

A. SUMMARY. 50 

B. RECOMMENDATIONS. 51 

C. OPEN RESEARCH QUESTIONS. 52 

LIST OF REFERENCES.53 

APPENDIX.55 

INITIAL DISTRIBUTION LIST.87 














LIST OF riGURBS 


Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 


1 Control Graph 5 

2 Scatterplot Progr 2 un 1 21 

3 Scatterplot Program 2 21 

4 Scatterplot Progreun 3 22 

5 Scatterplot Program 4 22 

6 Scatterplot Program 5 23 

7 Scatterplot Program 6 23 

8 Scatterplot Program 7 24 

9 Scatterplot Program 8 24 


10 

Scatterplot 

Program 

1 

32 

11 

Scatterplot 

Program 

1 

32 

12 

Scatterplot 

Program 

1 

33 

13 

Scatterplot 

Program 

1 

33 

14 

Scatterplot 

Program 

1 

34 

15 

Scatterplot 

Program 

1 

34 

16 

Scatterplot 

Program 

1 

35 

17 

Scatterplot 

Program 

1 

35 


VI 






LIST OF TABLES 


TABLE I VERSION SOURCE PROFILE 17 
TABLE II ANOVA V(G) VS. FAULTS 26 
TABLE III MEANS V(G) VS. FAULTS 29 
TABLE IV ANOVA LOG VS. FAULTS 38 
TABLE V MEANS LOG VS. FAULTS 40 

TABLE VI SUMMARY OF ANOVA TESTS V(G) VS. FAULTS & LOG 
VS. FAULTS 42 

TABLE VII SUMMARY OF MEANS TESTS V(G) VS. FAULTS & LOG 
VS. FAULTS 42 

TABLE VIII MEANS LOW V(G) LOG VS. FAULTS 45 
TABLE IX MEANS LOW LOG V(G) VS. FAULTS 47 








ACKNONLBDGEMENTS 


I would like to thank Prof. Timothy J. Shimeall for his 
efforts in providing the progreuns used as the basis for this 
study, and for his guidance and instruction that made possible 
the successful completion of this work. 

I would like to thank Prof. William J. Haga for his 
contribution, in providing a thorough review of this thesis. 

I would like to thank LCDR John Yurchak, USN for his 
assistance in resolving some of the prograimming aspects of 
this project. 

I would like to thank Nancy Leveson for her efforts in 
providing the programs used in this study. 





I. IMTRODUCTZOM 


A. IMPORTANCE OF SOFTNARB TESTING 

The question of software accuracy and reliability has 
become an important issue facing software developers, 
especially in the last decade. There has been an explosion in 
the demand for new software systems. Software is being 
applied to all facets of life, from relatively commonplace and 
unsophisticated transaction systems to unforgiving and time 
critical military and space applications. 

While hardware costs have gone down in the past decade, 
software costs are on the increase, mainly because software is 
being applied to increasingly complex and ever larger systems. 
Brooks aimusingly likens the unforgiving environment of 
software development to the precise and unforgiving 
incantations of the mythical medieval sorcerer. As with the 
incantations, the program must be constructed with absolute 
precision. [Ref. 1] Software can be seen as an almost 
magical solution to a multitude of problems, but software 
development, with all the benefits of structured design 
methodologies and programming tools, is still an activity that 
is highly human intensive and subject to all the vicissitudes 
and imperfections that go along with being human. 
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The consequences of even small software mistakes can be quite 

large. For example, there is the commonly told story of the 

spacecraft "Pioneer" that was unable to carry out its 

multimillion-dollar mission because of a single misplaced 

character. As costly systems become software dependent, both 

in terms of monetary value and the potential cost to human 

life, a system software must commensurately become more 

reliable and cost efficient. Software, ideally, should be 

reliable both in short term performance and in its zdDility to 

accommodate future requirements (maintenance). McCabe states: 

"That the issues of testability and maintained^ility are 
important is borne out by the fact that we often spend 
half of the development time in testing." 

[Ref. 2] 

In the same vein Boehm states: 

"In 1985, software costs totaled roughly $11 billion in 
the US Department of Defense, $70 billion in the US 
overall, and $140 billion worldwide. If present software 
cost growth rates of approximately 12 percent per year 
continue, the 1995 figures will be $36 billion for the 
DoD, $225 billion for the US, and $450 billion worldwide. 
Thus even a 20 percent improvement in software 
productivity would be worth $45 billion in 1995 for the US 
and $90 billion worldwide." [Ref. 3] 

Thus an improvement in testing that results in a 20 percent 

gain in efficiency would be worth somewhere between 28 and 90 

billion dollars in terms of worldwide savings annually. The 

ability to identify regions of code where software testing 
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effort should be concentrated could save developers both time 
and money, or result in more relizO^le systems for the same 
money. 

Software testing, like other phases of software 
development such as design, coding and debugging, is an 
activity that is extremely demanding of hxoman resources. It 
is not the sort of activity that can be greatly improved upon 
through the introduction of better or faster hardware, for 
example. Furthermore, complete testing is not theoretically 
possible. Three reasons are given for this inability to 
completely test a program in Beizer's "Software System 
Testing and Quality Assurance": 

"-We can never be sure that the specifications are 
correct. 

-No verification system can verify every correct 
program. 

-We can never be certain that a verification system is 
correct." [Ref. 4] 

Given that testing is an activity that is human resource 
intensive and that theoretically a program can never be 
completely tested, then it is reasonable to search for some 
tool to guide testing activities to minimize commitment of 
human resources and money. McCeibe suggests the cyclomatic 
complexity as just such a tool. [Ref. 2] 
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B. APPROACH 


1. Definition of Cyclomatic Coa^lexity 

The cyclomatic complexity is a mathematical technique 
that provides a quantitative basis for modularization and for 
developing a testing strategy, by evaluating source code in 
terms of logical decision points. The cyclomatic complexity 
is a measure of the number of paths in a pi3gram. One problem 
with measuring the possible number of paths is that where a 
backwards branch exists, there is the possibility of an 
infinite number of paths. Using the total number of paths is 
not a realistic approach. Therefore cyclomatic complexity is 
defined as the number of basic paths through a program. The 
cyclomatic complexity (v(G)) of a program is derived by 
associating a directed graph with it. In figure 1, a directed 
graph, each node (a - e) represents a block of code where the 
flow is sequential, and the arcs represent branches in logical 
program structure. [Ref. 2] 
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The McCabe complexity measure is based on the application of 

a graph-theoretic complexity measure to a program's structure. 

"Definition 1: The cyclomatic ntimber V(G) of a graph G 
with n vertices, e edges, and p connected components is 


v{G)=e-n+p. 


Theorem 1: In a strongly connected graph G, the 
cyclomatic number is equal to the maximum number of 
linearly independent circuits." [Ref. 2] 

Referring to figure one, an example of a linearly independent 

circuit in G is: a-c-f-a, where the starting point is a and 

the ending point is a. McCabe derives a simplified form of 

the cyclomatic complexity equation. In this simplified 

equation, the cyclomatic complexity (v(G)) equals the number 

of predicates (pi) plus one, where each predic?.*:- i r a 1 :j i 
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decision point such as "if-then" (refer to chapter 3 for a 
complete list of Pascal predicates to be evaluated): 

V{G) =7T + 1. 

This simplified form is easily automated in a tool for 
obtaining the cyclomatic complexity of a block of code. The 
cyclomatic complexity measure can be determined for each of 
the functions and procedures of a given progreim. The testing 
effort on the procedures and functions could, therefore, be 
concentrated on the basis of higher complexity (v(G)) values. 
The assumption would be that there is potentially a higher 
number of errors in these more complex procedures and 
functions. McCabe suggests a v(G) value of ten, as an 
indicator of where testing effort should be concentrated. 
[Ref. 2] 

2. Cyclomatic Complexity Measure and Lines of Code 

McCabe goes on to suggest that the measure of 
cyclomatic complexity is of greater utility as an indicator of 
potentially troublesome regions of code than the simple 
measure of lines of code (LOC) . Shortness does not always 
imply simplicity. A short module, consisting of a series of 
twenty five if-then's (i.e., a high cyclomatic complexity) has 
a large number of possible logical paths. 
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The cyclomatic measure, representing the inherent complexity 
of a module, would be a more reliable predictor of potentially 
faulty regions of code than the simple lines of code (LOC) 
metric. [Ref. 2] 

3. Use of An Experiment to Evaluate the Cyclomatic 
Conqplexity 

In light of the theoretical work developed by McCabe, 
the question remains as to whether there is a correlation 
between the complexity metric and what is actually born out 
through empirical analysis. There is also the question of 
how the cyclomatic complexity metric compares with other 
metrics. 

Few experiments have examined the incidence of errors 
with respect to the cyclomatic complexity measure. In a study 
by Walsh, the occurrence of errors was measured against 
cyclomatic complexity in eight functionally related modules 
(essentially one large program). These modules were comprised 
of 276 procedures or programs making up a software control 
loop and display processing for the Aegis Naval Weapons 
System. The error data were derived through the compilation 
of trouble reports. In the study, Walsh endeavored to 
distinguish between "software errors" and "design errors" by 
interviewing programmers responsible for the code. The study 
divided the procedures and programs into two groups, one group 
where cyclomatic complexity was less than ten and the other 
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group where it was greater, in order to compare the incidence 
of errors in the two groups. It was found that there was a 
21% higher incidence of errors in the group with a higher 
cyclomatic complexity. [Ref. 5] 

In a study by Schneidewind, four prograuns were 
examined for the correlation between the incidence of errors 
and the cyclomatic complexity. The four prograuns were 
programmed by the same prograunmer in Algol for execution on 
the IBM 360/67. Prograun one was 141 source statements. 
Program two was 712 source statements. Prograun three was 70 
source statements and prograun four was 1084 source statements. 
It can be seen that three of the prograuns were fewer than 1000 
source statements; one was just barely over that number. Two 
of the programs were in fact quite small (one and three) . The 
error data for these experiments were obtained through 
programmer-generated error reports. The experiment concluded 
that program structure (v(G)) would have a significant effect 
on the number of errors. In this study it was further stated 
that the relationship between errors and structure was not 
expressible as a mathematical function but serves to partition 
structures into high or low occurrence depending on whether 
the cyclomatic complexity is high or low. [Ref. 6] 

In a study by Basili, a database of ground supp''rt 
software for satellites was studied to invest i ua* ^ 
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relationship between program cyclomatic complexity and errors. 
In this study Basili examined systems rauiging from 51,000 to 
112,000 lines of Fortran source code. Each system was made up 
of from 200 to 600 modules (a total of 1794 modules were 
analyzed in the entire experiment). Error data were collected 
from change report forms. It was the conclusion of this study 
that there was a poor correlation of cyclomatic complexity 
with errors in these large programs. Basili cites a Spearman 
rank order correlation for cyclomatic complexity with faults 
of .196. The low correlations were attributed to the fact 
that 34 0 of the 652 modules analyzed with regard to errors had 
zero :.eported errors. [Ref. 7] 

In a study by Ward, two large scale programs were 
examined for correlation of errors to cyclomatic complexity at 
Hewlett Packard's Walthan Division. Projects A and B were 
125,000 and 77,000 lines of non-commented source code 
respectively. The two programs were independent of each 
other, had short development times and had a low post-release 
defect density. The error database for the experiment was 
compiled from prerelease development data that had been 
maintained on the programs. Ward concluded, that a .8 
statistical correlation was found between complexity and 
defect density. [Ref. 8] 

In a study by Butler, four small programs from 
operational ECM Software were studied. Program one was 118 
lines of code. Program two was 89 lines of code. 


9 





Program three was 173 lines of code and program four was 135 
lines of code. For each of the four programs a qualitative 
assessment of the programs was made in terms of 
maintainability, readability, comprehensibility and "bug 
detection". The data for this qualitative assessment were 
made over a period of two years on the basis of customer 
comments. It was the conclusion of this study that the 
cyclomatic complexity measure provides the "best" method to 
analyze and limit complexity of a software prograun. No direct 
correlation was found between the incidence of errors and 
cyclomatic complexity. A broad qualitative relationship was 
indicated. [Ref. 9] 

In a study by Meals, tools to automate complexity 
measures were coded in COBOL and applied against three, 
separate, large commercial COBOL programs. These programs 
were examined to determine if there was a correlation between 
cyclomatic complexity and the known error history of the 
software. In the course of the development of program one, it 
grew from 4956 lines to 5948. Program two grew from 4239 
lines to 5001 lines. Program three grew from 9416 lines to 
9425 lines. Two of the three programs showed correlations 
between the incidence of errors and the cyclomatic complexity 
(however no coefficient was given). The conclusion was that 
cyclomatic complexity was useful as an indicator of error- 
prone sections of code. [Ref. 10] 
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Henry, Kafura and Harris undertook a study of a 
single, large system (the UNIX operating system) in which 
cyclomatic complexity was compared to the occurance of errors. 
A list of errors was obtained from the tjNIX User's Group. A 
strong correlation (.95) was found to exist between 
procedures containing errors and cyclomatic complexity. 
[Ref. 11] 

Gollhofer, Shimeall and Leveson examined cyclomatic 
complexity with respect to errors in a group of 27 independent 
implementations of a multi-version software experiment. These 
programs ranged in size from 400 to 800 LOG and had an average 
execution time of three minutes. Faults were derived through 
previous testing studies. This study concluded that there was 
a strong correlation between higher v(G) (v(G) > 10) and the 
incidence of errors. Nine percent of the modules had a v(G) 
greater than ten; these same modules had 47% of the errors. 
[Ref. 12] 

The previous experiments that attempted to correlate 
the cyclomatic complexity measure with the incidence of errors 
fall into two groups: empirical studies on a series of 
relatively small (less than 1000 lines) programs using simple 
debugging efforts, and studies on a single 
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large prograun, using problem reports generated by in-field 
use. In general, the empirical work done to date suggests 
that there is a correlation between the incidence of errors in 
coding and the cyclomatic complexity measure. However, there 
has been no experiment that examined the correlation between 
the cyclomatic measure and the incidence of prograunming errors 
in a series of independently developed versions of a 
relatively large, complex prograun (larger than 1500 lines), 
each program having been subjected to strenuous fault 
detection efforts using a variety of detection techniques. 

C. PROBLSM STATEMENT 

Larger programs tend to manifest a greater incidence of 
errors by virtue of the increased ntimber of inter-dependencies 
that tend to be created. [Ref. 13] Therefore, the 
questions which have been approached in this endeavor are: 

• What is the predictive relationship between the cyclomatic 
measure of program complexity and the incidence of errors 
in a series of larger prograuns, i.e, does the relationship 
between the complexity measure and the incidence of errors 
hold true in larger programs as it does in smaller ones? 

This cpjestion addresses how well previous studies scale 

up: large programs are more than a set of concatenated small 

ones. In this study, the programs will be analyzed on a 

version-by-version basis, rather than mixing procedures 

together. Also, complex applications exibit in^ ; i'=>p--n i-n i 

and need to be examined as well. 
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• How do the results for the complexity metric compare with 
other similar metrics, notaQ^ly lines of code (LOC) ? Eb tte 
results of the comparison of cyclomatic complexity to 
errors and LOC to errors seem to parallel each other, or 
does cyclomatic complexity show a better correlation with 
errors than LOC? 

It is important to place results in perspective by use of 
other measures. The common complexity measure is LOC. It 
would also be interesting to test McCabe's assertion regarding 
the utility of LOC as a metric. Lastly, it is reasonedDle to 
test what is generally known to be a high correlation between 
cyclomatic complexity and LOC. 

D. OVERVIEW OF THE THESIS 

The remaining chapters of this thesis are structured as 
follows: Chapter II provides a description of the study 

undertaken, presentation of data and statistical analysis, and 
a discussion of the data with an interpretation of results. 
Chapter III provides a summary of results and conclusions. 


13 







II. DESCRIPTION OF EXPERIMENT AND RESULTS 


A. INTRODUCTION 

This chapter presents the methodology used in this 
experiment, and presents the data and conclusions generated in 
light of the questions pcsed in chapter one. In review these 
questions were: 

• What is the correlation between the v(G) of a procedure or 
function and the incidence of errors? 

• How does the cyclomatic complexity compare with Lines of 
Code (LOC) as a predictor of errors? 

B. EXPERIMENTAL METHODOLOGY 
1. TOOL FOR COMPUTING V(G) 

To make the comparison between the incidence of found 
errors and v(G), the v(G) had to be determined for each 
procedure and function within each of the eight programs, 
described in section C of this chapter. In accordance with the 
formula: 

v(G) =Tl + l 

cyclomatic complexity was calculated on the basis of 
predicates (pi) + 1. The following Pascal expressions 

constitute the predicates that were counted; 
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if-then 'a 
or' 8 
while 
for 

case (conditions) 

repeat 

Pascal Predicates 


Because of the size of the programs involved it was 
decided that the best approach to determining the number of 
predicates would be to develop a progrcun to automate the 
process on a modular (procedure and function) basis. The 
basis for development of such a program is lexigraphical 
analysis. The C programming language was chosen for this 
application. 

A software tool was then designed and coded to comprise 
two related functional components. The first functional 
component of the program is the lexical analyzer. The lexical 
analyzer reads in the input streaun (prograun) one character at 
a time. On the basis of the Standard Pascal Reserved Word 
List, the lexical analyzer identifies what in lexigraphical 
parlance are termed "tokens". One token is returned each time 
the lexical analyzer is called. The lexical analyzer was 
constructed such that each output token is se;i _ f 
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the streaun of characters making up the token and the token 
identity. The second functional component of the program is 
the parser. The parser calls the lexical analyzer, and 
through recursive descent the parser analyses the tokens in 
terms of all the legal constructs in the Standard Pascal 
language. Lastly on the basis of the recognition of the 
logical constructs the predicates are counted. The prograun 
generates each procedure or function name and the associated 
v(G) values. 

C. EXPERIMENTAL DATA BASE 

This experiment used eight Pascal programs (refer to 
section B for a description) that had already been subjected 
to rigorous debugging efforts. These programs were written 
for and were the subject of Shimeall's [Ref. 14] comparison of 
fault elimination and fault-tolerance techniques and 
comparison of various testing techniques in terms of fault 
detection. They were written from a single specification for 
a combat simulation problem, derived from an industrial 
specification. Development followed a standard, controlled, 
software life cycle approach. The development involved 26 
upper division computer science students working in pairs. 
Eight versions were eventually produced that were determined 
to be adequate for the purposes of the fault d^t i - n, l y 
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successfully executing a 15 case minimal acceptance test. 
Each program had been tested for errors and 255 faults had 
been identified and corrected, while preserving the 
originally faulty code by using conditional compilation flags. 

Table I describes the eight versions. The Modules column 
gives the number of Pascal functions or procedures in each 
version. The size of each version is given in terms of lines 
of source code and code lines. Code lines is the size of each 
version without comments and blank lines. Lastly, the number 
of errors detected in each version is given in the errors 
column. 


TABLE I VERSION SOURCE PROFILE 


Version 

Modules 

Source 

Code 

Errors 

1 

72 

7503 

2414 

35 

2 

56 

3452 

1540 

11 

3 

41 

1480 

1201 

33 

4 

57 

3663 

2003 

26 

5 

28 

1634 

1544 

25 

6 

72 

3065 

2206 

24 

7 

75 

2734 

1976 

23 

8 

57 

1896 

1331 

16 


Each version of the combat simulation program was subjected to 
five fault detection techniques. These fault detection 
methodologies were; code reading by stepwise abstraction, 
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static data flow analysis, run-time assertions inserted by 
the programi development participants, multi-version voting, 
and functional testing with follow-on structural testing. A 
fault was considered to exist where there was at least one 
associated identifiable misbehavior (or failure to perform a 
required function) in the program. A section of code was 
considered a single fault (or bug) where it's correction 
eliminated at least one failure. Several faults could 
possibly contribute to a failure for a particular data set, 
and several failures could be caused by a single fault. 
[Ref. 14] 

In the course of counting the previously identified 
faults, if there was more than one correction of code 
associated with the correction of a particular misbehavior, 
then only one fault was counted. 

In summary, this data set is unique because it provides 
eight independently developed versions of a single 
specification for a program. Because all programs were 
developed from a single specification, the variability of 
faults due to differences in design specifications car. be 
eliminated. Each version has been thoroughly debugged using 
the fault detection techniques. The faults in each function 
and procedure have been identified. Finally, the application 
is complex, with many input variables and much : ‘ .1 , an i 

each version is larger than 1200 lines of code (see Talle I). 
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The variability of faults with respect to cyclomatic 
complexity has not been tested on multiple program versions of 
this length, and complexity. 

D. HSSULTS 

Each of the progrzuns were analyzed individually (as 
opposed to grouping all the procedures and functions together 
from all eight programs) in order to allow individual program 
variation to be seen, thereby preventing the masking of one or 
more program variances by the entire group. Also, in order to 
determine if other metrics (i.e., LOC) predict faults better 
than cyclomatic complexity, it was necessary to look at 
multiple program cases, to estimate the population standard 
deviation. 

The non-parametric tests (ANOVA & Means) were chosen for 
the statistical analysis instead of a parametric test because 
no assumptions can be made eibout the population being 
normally distributed. These tests are relatively insensitive 
to the violation of normality. 

1. Relationship of V(G) to Faults 

The first c[uestion under investigation concerns the 
correlation between the incidence of faults and the value of 
v(G) . 
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m. SvaaoMry of Qbamrvmd Data 

Figures 2-9 are scatterplots depicting the 
cyclomatic complexity (on the x axis) in relation to the 
incidence of faults (on the y axis) in the procedures and 
functions, for each of the eight progreims. Each axis is 
leQ:>elled with a number indicating the maximum value for that 
variable for each progrzun. An asterisk represents one 
occurrence at the indicated x,y position. A ntomber represents 
the n\imber of functions or procedures occurring at the 
indicated x,y position. Lastly, the pound sign (#) is 

indicative of ten or more occurrences of functions or 
procedures at the indicated position. 
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There is probaibly not a linear relationship between 
cyclomatic complexity and faults, but inspection of the data 
indicated that the majority of the functions and procedures 
with faults have a cyclomatic complexity greater than seven. 
There are, however, a small number of faulty procedures and 
functions where there is a cyclomatic complexity less than 
seven. 

b. Analysis of Obssrvd Data 

To further explore what appeared, through 
inspection of the data, to be a relationship between higher 
values of v(G) and faults, two statistical tests were applied 
to the data: the ANOVA Test and the Means Test. 

(1) ANOVA Tests. Functions and procedures for 
each program were first ordered according to v(G), from least 
to greatest, with each associated fault count, and then were 
divided into thirds: 

• v(G) fewer than six, the fault count mean of which is 
designated : 

• v(G) from six to ten, the fault count mean of which is 
designated: 

m2 

• v(G) greater than ten, the fault count mean of -which is 
designated: 
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The null and alternative hypotheses in the one-factor ANOVA 
model are: 

Hoi :^l=^2=n3 


Hal: at least two of ths population means are not equal. 

TeJsle II provides a summary of the resultant ANOVA Test 
probabilities. 


TABLE 11 ANOVA V(G) VS. FAULTS 


Version 

Probability 

1 

.00001308 

2 

.10820000 

3 

.00288300 

4 

.02930000 

5 

.10570000 

6 

.37630000 

7 

.00151100 

8 

.12800000 


Hoi can be rejected on the basis of four 
programs (one, two, four and seven) at the .05 alpha level. 
Additionally, if the alpha level of acceptance is broadened to 
.10 the rejection of Hoi is supported on the basis of 
programs three and five). Program eight is just beyond the 
.10 alpha acceptance level and does not support *-h-. 
of Hoi. The mean value for all eight probabilities is .0940 
with a standard deviation of .1260. 
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This mean value of .0940 does not support the rejection of Hoi 
at the .05 alpha level of confidence. If, however the alpha 
level is broadened to . 1 then the mean for the ANOVA 
probabilities does support the rejection of Hoi. The ANOVA 
probability of program six is clearly an outlier. It is more 
than two standard deviations (standard deviation = .1260) from 
the mean value (.0940) for all eight probaO^ilities generated 
by the ANOVA tests. The behaviors that make version six an 
outlier are interesting, and are explored at the end of this 
chapter. If it is disregarded then the mean value probability 
for the remaining programs is .05 with a standard deviation of 
.05. The mean value of this probability supports the 
rejection of Ho at the .05 level. In summary, (taking into 
account program six) the ANOVA tests do support the rejection 
of Hoi, and do support the acceptance of Hal, the hypothesis 
that the differences between the numbers of faults in the sub¬ 
groupings of procedures and functions is due to more than 
chance. Because the procedures and functions for each 
program were divided into three groups on the basis of 
cyclomatic complexity, a relationship between faults and 
cyclomatic complexity is indicated. 

{2) Means Tests. To further substantiate the 
results obtained with the ANOVA tests with regard to the 
relationship between the cyclomatic complexity and the 
incidence of faults, a means test was similarly performed on 
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each of the eight progreuns. The t distribution was used in 
this test because the fault population standard deviation is 
unknown. The procedures and functions were ordered according 
to v(G) as with the ANOVA Teats, amd then were divided into 
two groups, those with a v(G) less than six auid those with a 
v(G) greater than five. 

• v(G) less than six, the fault count mean of which is 
designated : 

ol 

• v(G) greater than five, the fault count means of which is 
designated: 

02 

The null and alternative hypotheses in the Means model are: 
Ho2:al-o2 

Ha2:cl*o2 
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Table III provides a svunmary of the resultant Means Tests 
probzibilities. 


TABLE III MEANS V(G) VS. FAULTS 


Version 

Probability 

1 

.0029840 

2 

.0212000 

3 

.0251000 

4 

.0625000 

5 

.0291000 

6 

.0825000 

7 

.0225000 

8 

.0492000 


On the basis of the probabilities derived 
through the Means Tests, Ho2 can be rejected on the basis of 
six programs (one, two, three, five, seven and eight), at the 
,05 alpha level. If the alpha acceptance level is extended 
to .1, programs four and six support the rejection of Ho2. 
The mean value for all eight probcibilities is .0365 with a 
standard deviation of .0264, and it supports the rejection of 
Ho2 at the .05 level. 

In summary, the Means Tests do reject Ho2 
and support the acceptance of Ha2, the hypothesis that the 
differences between the mean values of the subgroupinas of 
procedures and functions is due to more than cli'.n . Ii. 
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other words, a relationship between higher values of 
cyclomatic complexity and the increased incidence of faults is 
suggested by both the ANOVA Tests and the Means Tests. 

It is important, however, to place this 
support in context. In real testing efforts, tests are 
carefully planned, and part of this plamning involves the use 
of metrics. Thus, whether cyclomatic complexity predicts 
faults in isolation is less useful than whether it predicts 
better than other commonly used metrics. This issue is 
explored in the next section. 

2. Relationship of Cyclomatic Complexity to Lines of Code 
The second qpaestion under investigation concerns the 
comparison of cyclomatic complexity with Lines of Code (LOC) 
as a predictor of faults. In order to make this cc'mparison, 
the incidence of faults in the procedures and functions for 
each program was examined in comparison to the respective LOC 
for each procedure and function. 
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a. Summary of Obamrvmd Data 

Figures 9-16 are scatterplots depicting the Lines 
of Code, on the x axis, as a function of the incidence of 
faults, on the y axis, of the procedures and functions, for 
each of the eight programs. Each axis is labelled with a 
number indicating the maximum value for that variable for each 
prograun. An asterisk represents one occurrence at the 
indicated x,y position. A number represents the number of 
functions of procedures occurring at the indicated x,y 
position. Lastly, the pound sign (#) is indicative of ten or 
more occurrences of functions and procedures at the indicated 
x,y position. 
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Figure 12 Scatterplot Program 1 
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There is probably not a linear relationship between 
LOG and faults, but inspection of the data indicated that the 
majority of the functions and procedures with faults have a 
size, in terms of LOG, greater tham 30. There are however, a 
small number of procedures and functions where the Lines of 
Gode measurement is less than 30 with the presence of faults. 
b. Analysis of (^ssrvsd Data 

As with the statistical tests to determine if there 
was any relationship between the incidence of faults and the 
cyclomatic measure, the relationship between the measure of 
Lines of Gode (LOG) and the incidence of faults was examined 
using the ANOVA and the Means Tests. 

(1) ANOVA Tests. Functions and procedures for 
each program were first ordered according to LOG, from least 
to greatest, with each associated fault count. The data were 
divided approximately into thirds with respect to the total 
number of procedures because there were large numbers of 
procedures with the same cyclomatic complexity value, 
especially in the lower cyclomatic complexity value range. 
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The procedures and functions were divided into the following 
groups; 

• bottom third with respect to the total of procedures, the 
mean fault count of which is designated: 

• middle third with respect to the total of procedures, the 
mean fault count of which is designated: 

• upper third with respect to the total of procedures, the 
mean fault count of which is designated: 

The null and alternative hypotheses in the one-factor ANOVA 
model are: 

Ho3 : |il =ia2 = n3 

Ha3: at least two of the population means are not equal. 
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Table IV provides a summary of the resultant ANOVA Test 
probabilities. 


TABLE IV ANOVA LOG VS. FAULTS 


Version 

Probability 

1 

.00019740 

2 

.04930000 

3 

.00617900 

4 

.01770000 

5 

.08410000 

6 

.19170000 

7 

.04070000 

8 

.10230000 


:)n the basis of the probabilities derived through the ANOVA 
tests, Ho3 can be rejected on the basis of five programs (one, 
two, three, four and seven), at the .05 alpha level. If the 
alpha tolerance level is broadened to .10, programs five and 
eight further support the rejection of Ho3. The ANOVA 
probability of program six is rather high and tends not to 
support the rejection of Ho3. The mean probability for all 
eight programs for the ANOVA tests is .0615 which does not 
support the rejection of Ho3 at the .05 alpha level. It 
should be noted, however, that the probability derived through 
the ANOVA test of program six is nearly two standard 
deviations (standard deviation = .0637) from the mean value 
(.0615) for all probabilities generated by the 
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ANOVA tests; as such it is an outlier. If the ANOVA 
probed^ility of program six is discarded then the mean value 
probaibility for prograims one, two, three, four, five, seven 
and eight is .0429 with a standard deviation of .0389. Tne 
mean value of this probability supports the rejection of Ho3 
at the .05 level. In summary, if program six is considered an 
outlier, the ANOVA Tests do reject Ho3 and support Ha3, the 
hypothesis that the differences between the numbers of faults 
in the sub-groupings of procedures and functions are due to 
more than chance. Because, as was previously stated, the 
procedures and functions for each program were divided into 3 
groups on the basis of LOG, it is suggested that there is a 
relationship between LOG and the incidence of faults, as was 
the case with cyclomatic complexity. 

(2) Means Tests. A Means test was also 
performed on each of the eight programs in order to further 
substantiate the results of the ANOVA Tests. The t 
distribution was used in this test because the fault 
population standard deviation is unknown. The procedures and 
functions were ordered according to LOG, and were roughly 
divided in half according to the number of procedures and 
functions. This is entirely analogous to the division into 
thirds of the previous section. 
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The data are represented as follows: 


• bottom half with respect to the total of procedures, the 
mean fault value of which is designated: 

ol 

• upper half with respect to the total of procedures, the 
mean fault value of which is designated 


o2 

The null and alternative hypotheses in the Means model are: 


Ho4 :o1 = O 2 


Ha4:al*a2 


Table V provides a summary of the resultant Means Tests 
probabilities. 


TABLE V MEANS LOC VS. FAULTS 


Version 

Probability 

1 

.00173800 

2 

.00932300 

3 

.00768200 

4 

.01250000 

5 

.01720000 

6 

.02750000 

7 

.06980000 

R 

.01160000 
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Ho4 can be rejected on the basis of seven programs (one, two, 
three, four, five, six, and eight), at the .05 alpha level. 
Additionally at the .07 alpha level prograun seven supports the 
rejection of Ho4. The mean value of all eight probability 
results from the Means Tests is .0197 with a standard 
deviation of .0216. In summary the Means Tests support the 
rejection of Ho4 and the acceptance of Ha4, the hypothesis 
that the differences between the ntambers of faults in the sub¬ 
groupings of procedures and functions is due to more than 
chance. In other words, a relationship between higher 
measures of Lines of Code (LOG) and the increased incidence of 
faults is suggested by both the ANOVA Tests and the Means 
Tests. 

c. Comparison of Cyclomstic Complmxity and LOC as 
Predictors of The Incidence of Faults 

Tables VI and VII provide a summary comparison of 
the results obtained from sections a and b. The column 
entitled ANOVA Cyclo (Table VI) lists the probeODilities 
derived from application of the ANOVA Test to the programs in 
order to loo)c at the faults as a function of the cyclomatic 
complexity. The column entitled ANOVA LOC (Table VI) lists 
the probabilities derived from application of the ANOVA Test 
to the programs in order to look at the faults as a 
function of the Lines of Code. The column entitled Means 
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Cyclo (TeQDle VII) lists the probzJ^ilities derived from 
application of the Means Test to the programs in order to look 
at the faults as a function of the cyclomatic complexity. And 
lastly, the column entitled Means LOC (TzdDle VII) lists the 
probadDilities derived from application of the Means Test to 
the programs in order to look at the faults as a function of 
the Lines of Code. 


TABLE VI SUMMARY OF ANOVA 
TESTS V(G) VS. 
FAULTS & LOC VS. 
FAULTS 


Version 

ANOVA CtcIo 

ANOVA LOC 

1 

.00001308 

.00019740 

2 

.10820000 

.04930000 

3 

.00268300 

.00617900 

4 

.02930000 

.01770000 

5 

.10570000 

.06410000 

6 

.37630000 

.19170000 

7 

.00151100 

.04070000 

6 

.12800000 

.10230000 


TABLE VTI SUMMARY OF 
MEANS TESTS 
V(G) VS. FAULTS 
& LOC VS. FAULTS 


Version 

Means Crclo 

Means LOC 

I 

.00029840 

.00173800 

2 

.02100000 

.00932300 

3 

.02510000 

.00768200 

4 

.06250000 

.01250000 

5 

.02910000 

.01720000 

6 

.08250000 

.02750000 

7 

.02250000 

.06980000 

6 

.04920000 

.01160000 


Inspection of the ANOVA tests (see tcible VI) shows 
that the probabilities were lower for the cyclomatic 
complexity than the LOC in three of eight the programs (one, 
three and seven) . In the other five programs (two, four, 
five, six and eight) the probabilities were 1 w--. : 

than the cyclomatic complexity, possibly .ndira*. ir. 




42 












a stronger relationship between size (LOG) and the incidence 
of faults. Inspection of the Means tests (see Table VII) 
shows that the ANOVA probabilities were lower for cyclomatic 
complexity as apposed to LOG in only two cases (one and 
seven) . 

The two columns of data shown in Table VI were compared 
using a Means test to determine if there existed a 
statistically significant difference between them. Similarly, 
a Means test was applied to the two columns of data in Table 
VII. 

(1) Means test V(G) verses LOG for ANOVA Tests, 
A Means Test was performed on the 

probability results derived from the ANOVA Tests on the two 
groups; faults as a function of cyclomatic complexity and 
faults as a function of LOG (see table VI). The means test 
produced a probability of .1921, which does not support the 
rejection of the equivalency of the two groups at any 
reasonable alpha level. In other words, it cannot be stated 
that there is a stronger relationship between cyclomatic 
complexity and faults than LOG and faults or vice versa with 
regard to the ANOVA Test probabilities. 

(2) Means test V(G) verses LOG for Means Tests. 
Additionally, a Means Test was conducted on 

the probability results derived from the Means Tests on 
the two groups: faults as a function of cyclomatic 
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complexity, and faults as a function of LOC (see table VI 
columns four and five) . The means test produced a probaQjility 
of .0854, which does not support the rejection of the 
equivalency of the two groups at the .05 alpha level. 

d. Low LOC with FMultm Mnd Low V(G) with Faults 

In order to further examine the relationship 
between cyclomatic complexity and LOC, the procedures and 
functions containing faults with low cyclomatic complexity or 
low LOC were examined to determine if there was a higher 
incidence of the other factor (higher LOC in the case of 
procedures or functions with low cyclomatic complexity and 
faults for example) to explain the faults. 

(1) Statistical Tests to Examine Procedures with 
Low V(G) and faults. As previously stated, it was observed by 
inspection of the data that there appeared to be a higher 
incidence of faults in procedures and functions with a v(G) of 
roughly greater than 7. The Means tests and ANOVA tests 
support the contention that the differences in mean faults 
between low cyclomatic complexity procedures/functions and 
higher ones is due to more than chance. In this section, 
faulty procedures and functions with cyclomatic complexity 
values less than seven are examined to determine if there is 
any support for correlation between LOC and faults in these 
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procedures. The procedures and functions with a v(G) of less 
than seven were divided into two groups to compare LOG: 

• faults present, the mean of LOG which is designated: 


• no faults present, the mean of LOG which is designated: 


The null and alternative hypotheses in the Means model are: 

Ho 5 :oi=o2 

Has:al*a2 


Table VIII provides a summary of the resultant Means Tests 
probabilities. 


TABLE VIII MEANS LOW V(G) LOG 
VS. FAULTS 


Version 

Probability 

1 

.064000 

2 

.259900 

Q 

w 

.017200 

4 

.025300 

5 

.020900 

6 

.050800 

7 

.010400 

8 

.006272 
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Programs three, four, five, six, seven and eight support the 
rejection of Ho5 and the acceptance of Ha5 at the .05 alpha 
confidence level. Additionally if the alpha level is 
broadened to .10, prograun one supports the rejection of Ho5. 
The probability for program two is more than two standard 
deviations (.08) beyond the mean for all eight prograuns (.05) 
and as such is an outlier. The mean probaUD: lity for all eight 
programs (.05) supports the rejection of Ho5 and the 
acceptance of Ha5 at the .05 alpha level. Inspection of the 
data revealed that in all programs the mean values of the LOG 
were higher in the groups with the presence of faults than in 
the group without them. In svimmary, there does appear to be 
support for a relationship between the faulty procedures and 
functions with a v (G) of less than seven and hig.ier values 
for LOG. 

(2) Statistical Tests to Examine Procedures with 
Low LOG and Faults. It was also determined upon inspection of 
the data and because of supporting results from Means tests 
and ANOVA tests that there was a higher incidence of faults in 
procedures and functions larger than 30 LOG. Similarly, as in 
the previous section, the Means Test was used to examine 
any correlation between v(G) and the incidence of 
faults in procedures with a size of less than 31 
LOG. The procedures and functions with a Lines of 


46 







Code count (LOC) of less than 31 were divided into two groups 
to look at V(G): 

• faults present, the mean value of v(G) which is 
designated: 


ol 

• no faults present, the mean value of v(G) which is 
designated: 


02 

The null and alternative hypotheses in the Means model are: 


Ho6 :o1 = o 2 


Ha6 : al*a2 


Table IX provides a summary of the resultant Means Tests 
probabilities. 


TABLE IX MEANS LOW LOC V(G) VS. 
FAULTS 


Version 

Probability 

1 

.085100 

2 

.364200 

3 

.308700 

4 

.477000 

5 

.111000 

6 

.181500 

7 

.160400 

8 

.218500 


47 







On the whole the resultant probaUbilities for all eight 
prograuns do not support the rejection of Ho6, with the 
possible exception of program 1. In other words there is 
virtually no support, in those procedures and functions with 
a LOG size of less than 31, for a relationship between faults 
and increased cyclomatic complexity. 

(3) Means test comparison of probabilities from 
tables VIII and IX. In order to verify that there was no 
equivalency between the resultant proba±>ilities obtained in 
subsections (1) and (2) , a Means test was conducted on the 
probabilities from tables VIII and IX. The resultant 
probability was .003121, thus the equivalency of the two 
groups is rejected. 

3. Summary of Results 

In summary it was found, that with respect to the 
programs analyzed in this study, there does appear to be a 
correlation between the cyclomatic complexity and the 
incidence of faults. A correlation between the simple measure 
LOG and the incidence of faults was also found, but not 
significantly different from the correlation with cyclomatic 
complexity. Procedures and functions with a low cyclomatic 
complexity (v(G) < 7) that contained faults did exhibit a 
significant correlation between faults and LOG, but the 
converse was not true, in that small procedures and functions 
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(LOG < 31) with faults did not tend to have higherv(G) 
values than procedures without faults. 

Lastly there is the question of the results of prograun 
six: in the case of the ANOVA test of faults with respect to 
cyclomatic complexity, six was the exception and as such did 
not exhibit a correlation between cyclomatic complexity and 
faults. Examination of this prograun in closer detail with 
respect to the location of faults has shown that, of those low 
v(G) procedures and functions with faults, 5 of the 11 total 
low v(G) faults were related to variad)le initialization or 
assignment, 2 were parameter passing faults and one was a 
calculation fault. In other words, just over 70% of the low 
end errors appeared to be related to complexity factors that 
are not directly linked to the incidence of decision nodes or 
logical branching (cyclomatic complexity). 
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III. SUMMARY AMD CONCLUSIONS 


A. SUMMARY 

This study must be viewed in the context of the progreuns 
that were examined. The programs were developed by student 
coders in a university course environment, and are not 
necessarily representative of a commercial programming 
environment. Further, although the programs that were 
examined were thoroughly and rigorously debugged using various 
testing techniques (as indicated in chapter 2), and all eight 
versions essentially were subjected to the equivalent of unit 
testing, the programs were not further tested at a systems 
integration level of testing. These programs, being multiple 
versions of one design specification, simply are not suited to 
such an endeavor. 

The results of this study have added to the general body 
of knowledge concerning the relationship of the cyclomatic 
complexity to the occurrence of faults. Firstly, this 
analysis of multiple versions of complex, relatively large 
programs (ranging in size from 1200 to 2400 LOC) indicates 
that there is a correlation between faults and the cyclomatic 
complexity measure. Further, it was found in this study that 
the results of the analysis of LOC to faults roughly 
parallels the relationship of cyclomatic complexity 
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to faults. It could not be detexrmined in this context whether 
cyclomatic complexity or LOC had a stronger relationship to 
faults. Additionally, it would be interesting to undertake a 
similar study, based on the more thorough testing and 
accumulation of fault data, at a systems integration level of 
testing, and in a commercial environment. 

B. RECOMMENDATIONS 

With regard to the process of software testing, the 
cyclomatic complexity measure is supported as a predictor of 
potentially faulty regions of code, and as such it is a tool 
that the software manager could use to facilitate a more 
successful testing strategy and subsequent testing. On the 
other hand, because these results indicate that there is a 
correlation between larger modules and faults, and given that 
LOC is a very easily obtained metric, the software manager may 
be well advised to utilize LOC as opposed to cyclomatic 
complexity. A more cautious approach would, however, be the 
employment of both cyclomatic complexity and LOC as mutually 
supportive predictors of faulty code regions, as these two 
metrics both seem to parallel each other with regard to fault 
prediction. 
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C. OPEN RBSKARCH QUESTIONS 

There are several interesting research questions that have 
arisen in the course of this study which remain to be studied 
with regard to complexity issues. There is, for example, the 
issue of how to deal with cases where the cyclomatic 
complexity is not a predictor. Version six seems to fall into 
this category, considering the results of the ANOVA test. 
Another issue is how metrics cam be developed to predict 
faults in relatively short (less than 30 LOG) and simple (in 
terms of cyclomatic complexity) modules. Intra-modular 
complexity is addressed by cyclomatic complexity. However, 
inter-modular complexity, which is potentially a rich source 
of faulty code, is not addressed by the cyclomatic complexity 
measure. These questions remain open to further research 
work. 
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APPENDIX 


Progreun (parsel.c) is included as an appendix because it 
was developed specifically for this study as a tool designed 
to automatically calculate the cyclomatic complexity of 
procedures and functions in eight relatively large (1200-2400 
LOC) Pascal programs. The use of such a tool greatly 
facilitates the determination of cyclomatic complexity (which 
is often referred to as a lexical metric) , what would 
otherwise be a tedious and error prone activity. This is 
particularly true of this study, in which the programs 
analyzed were very complex in terms of the level of nesting, 
the depth of procedural scoping, and the length and complexity 
of constructs. The programming methodology employed in this 
lexical analyzer and parser is recursive descent. 
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I* prog! am 
*pt ogiamino 
*datc last revision 
*rompuier 
*1 ompilci 
* 


parse I c 

Edwin A. Shuman 
8 March 1990 
Vox 11/785 

Berkeley C Compiler (4.3BSD) 


*program description: This program is a pascal lexical analyzer and parser. 

* It is designed to read a pascal source file and 

* output a stream of tokens. Each token is comprised of 

* a "C" Structure containing the token itself 

* and its identification The tokens are interpreted 

* according to the Backus—Naur Form for the Pascal 

* Language. On the basis of the gramnuttical contstructs 

* (specifically the Pascal Predicates: if—then, while, 

* repeat, case (conditions), for, or) the Cyclomatic 

* Complexity is derived 
» / 


#lnclude <ctype.h> 

#include <ctype.h> 

#Uiclude <stdi(>.Ii> 

#denne 

TRUE 1 

#deflne 

FALSE ti 

#denne 

JUKI 251 

#defliie 

array 2,“'I' 

#denne 

_bcgin 25^ 

#denne 

cas'c 2rili 

#denne 

const 26! 

#denne 

div 262 

#d«nne 

_do 26.^ 

^define 

downto 26*1 

#deflne 

else 26.1 

#defiiie 

end 266 

^define 

_filc 267 

^define 

for 2f'S 

#diTne 

_function 26d 

' lei. le 

goto 270 

'H. n ,e 

_if 271 

#dei1ne 

in 272 

^define 

label 27". 

^define 

mod 274 

#denne 

jiil 215 

#denne 

not 270 

#denne 

“of 277 

^define 

_or 27S 

#denne 

_packcd 219 

fdeflnc 

piiKcduic 2S( 

#denne 

program 2111 

#denne 

record 2S2 

#dfnne 

rcpc.al 2H' 

#denne 

set 2K.1 

fdefine 

then 2H.1 

#denne 

to 2Sr, 

#denne 

type 2K7 

Odefine 

until 2.'<'' 

#denne 

vai 2'to 

^define 

svhile 2^1 

#denne 

o-iih 2't2 

^define 

idem 2''< 

#derine 

iiil 264 
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#deflne real 2^5 
#define _string 2% 

#deniie assign 297 
«denne jlus 298 
#defloe _ad<Jing_op 299 
#denne divide 3(K) 

#deflne leftpar ,701 
#defiDe _rightpar 302 
#denne _colon 30? 

<ld<*^ne _scniicol 304 
#denne ccMiinia 305 
#dcfliie _leftbrai.'e 306 
#denne _rightbrace 307 
#denne _period 308 
#defliie _pointer 309 
#deniie mult 310 
^define _exp 311 
^define dotdol 312 
#denne _relalioiial_op 313 
#denne minus 314 

n'scnc is i7n anav of sliurniK’s »hnli holds aU of the ptisctil 

” resetseJ »oiils 


struct { 

char \v(ird(12|. 
Int \aluv. 

) teseivf( I = 



and. 

army. 

anay. 

"begin’, 

l;"gin. 

"case". 

case. 

"con St". 

const. 

"div", 

div. 

"do". 

_do. 

"downlo". 

downto. 

"else". 

else. 

"end". 

end. 

■Tile' , 

file. 

"for". 

_fot. 

"tuiKiK’n". 

function. 


goto. 

"it . 

jf. 

"in’. 

in. 

"lalx*!". 

I.d'el, 

"nind". 

mod. 

’ tiir. 

“nil. 

"not". 

not. 

"nr. 

“of. 

’ Of 

oi. 

' patkctl". 

pa.kcil. 


procrdiiic 

’ fMogfam". 

piograni. 

"rccdi'T . 

ICCOld. 







): 


"with", 
"any_other", 


with. 

ident, 


/♦ lexrec is a type definition of a ilructuie which is the format of the token 
* relumed by Iex() 

*1 


typedef struct { 

char tok[15], 
tut toktype; 

) Icxrec; 

lexxcc token, lemptok, templok2, temptok?, teniptok4. teniptokS; 

Icxret stack(30]; 

int use_tcnip_tok. count; 

static lot line: 

static int Iokflag,tokflagl,tokilag2,tokflag3,tokflag4 - 0; 

static int sc = -1; 

/* lexdigiilcl IS called if the standard input character is a digit */ 
/* returns token * / 


lexdigit(c) 

char c; 

{ 

int cl. 

i: 

float value dec: 

i = 0; 

while (isJigiKcii { 

token.Ickiypc = _inl: 
token.loklil =■ c; 
c = gelc(siilin): 
i + + : 

) 

If (c == E ) { 

tokcn.tok[i| = c: 
token,toktype = _real. 
c = getctstclin i: 
i + c: 

If (tc '+') II Ic == II (isdigit(c))) { 
tokcn,tok(i| = c; 
i + + ; 

c - gctc(sidui): 
while (isdigiucll { 
tokentok[i| = c; 
c = getcistdinn 

) 

} 

unpc’lcic.stdin). 

return, 

> 

If (c -- I ( 

tl - « s|«|||i I 

If ((I I' { 

ffikrn iMktypr - _rcal: 

lr»kf(i,|nk( 11 - 
i *- * . 

lokcn lf>k|i| - tl 


lexdigit 
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c = getc(stdin); 
i++; 

while (isdigit(c)) { 
token.tokli] = c; 
c = getc(stdin); 
i++: 

) 

if (c == 'E ) { 
i++; 

token.tokfi] = c: 
c = getc(stdin); 
i++; 

If ((c = '+') II (c = II (isdigit(c))) { 
token.tok[i) = c; 

t++; 

c = getc(stdin): 
whilet isdigit(c)) { 
token.tok(i| = c; 

<_■ = getclstdin); 

' + +; 

} 

) 

) 

ungctLlc.stdin); 

return. 

) 

else if (d =- .1 { 
slapyl teniplok.lok. 

teinptok.toktypc = doldoi; 
usc_tenip_tok = TRL'E; 

I 

) 

* if the next I hjr afiei the iru vu/t n"t T. in ' ' * 

else { 

ungelett. sldinl; 

return: 

> 

> 


* lexjl/hui i> eiiUed if the staruieiiii in/ni' ix a letter <rr rniniher * ‘ 

lexalpha'i. ) Ic.XCllpIlO 

char c: 

( 

int I. 

1 = (t; 

while (dsalnunid. II (c =- i) { 
token.t(ik|i| = c: 

1. = gctcl stdin i; 

1 ♦ + : 

I 

tc'kcn toktvpc = idciil_t<'ken(token.Ink). 
ungct'.tc, sidin). 


■* ttilh'it il xtihri IX net it letle' er a Jictt * 
* leturre- trhen "* 




lex-;'.' It'. Ill ' I 

char I 

( 


U .\AM /7( h 







int i. 

d. 


8witch(c) { 

case /* a string *l 

token.tok|n| = A' ; 
c = getftstdin); 

i - 1 ; 

while (i- ! = \ ) { 

token.tok[i) = c; 
c = gelc(stdin); 
i++; 

) 

c = getc(<;tdin 
If (L- =- V') { 

c = gelc(stdin); 

while (c != A") { 

token l(ik(i| = t; 

L = gclc( <;tdin); 

i+ + . 

> 

lokcn.lnk(i| = ^ 
token.toklype = _stnng: 

break: 

) 

el.so { 

ungctrte ."stdin): 

token tok|i | = : 

token 'oktNpe = _flnnc; 

break. 

) 

break: 

ca.se - : 

token iok((l| = 

token toktype - relational op: 

break: 
case I 

token.tok|(t| = ) : 

token.toklyiK- - _tiglil[iai: 

break 

case 

e = geld stilin ). 

If le { 

sircpvl token.tok. ' : = "i: 
token.loki'< (x- - a.ssign. 

> 

else ( 


token.iok(li| ^ 
token loklvjv. (cilon: 
iiturclLii. i: 

) 

break: 

case 

token lok|('| “ 
token toki V|v - setiii'ol 

break 

case 

io| .11 |ok|ti| 

token |oktv|V' ( onnii;i 

break 

case I 

Ink en lok (ll| I . 
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token.tokfype = leftbrace; 

break: 

case 

token.loklO] = 
token.toktype = _riglttbrace; 

break; 

case 

token.tok(0] = 
token.toktype = _period; 

break: 

case 

token.tokjO] = " : 
token, toktype = _pointer: 

break. 


case ■/ : 

token.tok|('l = ' 

token.toktype = _di\'ide; 
break: 
case + . 

token.lok((i| = + ; 
token.tokiyi^e - plii>.-; 
break: 
case - : 

token.tokft'l - 
tt'kcn tokly[x- = minii'!; 
break, 
case '* : 

If != di { 
token.lok((i| = 

token.toktvpe = _ntult; 

> 

break: 
case < : 

d = getct'tdin': 

If = I ( 

strcpyi token.tok. "<="i: 
token.tokf.j>c = _relntional_op: 

) 

else If (d == > 1 ( 

stn. pel token.tok. ' (; 

tc’kcn.toktype = telational op: 

) 

else { 

stn-pvitokcfi.ti'k, ” I. 

token.loktsyie - relational op; 

iinitetet d.stilin ). 

) 

break. 


case ' 

(1 - jtete I-^tilin I. 

If (.1 -- , { 

etre pvt t<'ken tok 

tokeii tnkn[v - icl.ition.il o|. 

> 

else ( 

e - neti''.i,|in ' 

If le' • { 

>1111, ['M ti’keii.tnk , I. 

tokei; lokf.p T■.■|,lt|on.l! 

I 

else ( 

■^in pMti4 -n |i4 . . 1 , 


op 
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token.loktj’pe = _relational_op; 

ungetcie.stdin); 

ungetci^d.stdin); 

} 

) 

break: 

) 

) 

/♦ idcni jokend) compares the token to the list of pascal reserved words 
* returning the resen ed word identification if found 

*, 

idenl_loken(l) 

char *1; 

{ 

Int i. 

f, 

fduiul. 

I = (I. 

finind = FALSE; 

while (Ifourul && strcmp(reservefi] word, ■'any_otlier")» { 
if (istremp (leservclil-word. IH 
found = TREE: 

else 

lt^; 

) 

relurn (rc<;cr'’e|i|,valuci; 

I 

token sell) sets all of the elements of the array token rok whieh is part of * the 

token set() { 

Ini i: 

for (i = 0; i < 1.“': i ‘■4-I { 
token.toklil = Ml ; 
token toktvpe = _colo; 

) 

return: 

) 


Icrice lc\i I I 
Int e, d; 

Static int lefibraceflag = I); 

If (ii'ie tcnip tokI { 

use ternp l"k = (I. 
returnuetnptok i; 

) 

else ( 

t - petcistdini; 
token .set'): 


) 


while I'e -- 

if H -- 'll ) ( 

* piinpi h’u M tt 
bne * •, 

) 


) |l “ ''ji') |! (c == '\1 II { 

'‘ m / hni' *. * 


ident token 


struelure of a token to 0 

token set 
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contl: If (c = '(') { 
d = gelc(stdin): 

If (d = '♦') { 

c = gelc(sttlin); 
while (c != '*') { 

If (c = An') { 
luie++; 

) 

c = getc(sldm); 

) 

c = getc(sldin)', /* rightpar *1 
c = getc(stdin); 

If (((.■ = ■ ■) II (c = ^n') II (c = ^l')) 
goto cont; 

) 

else { 

token.lokfO] = 

token.loktype = leftpar. 

ungetcld. stdin): 
relurn(loken); 

) 

1 

!f(e == -{■) { 
while (c != '}'l { 

i: = gelc(stdin); 

If (e == \i') { 

printfl"Iinc f.t # line): *. 

linc*4: 

) 

) 

t = gelt(^ldin): 

if l(t =- ') li ic == 'Sn') II (c == 

polo coni. 

If ic == ( ) 

golo conll. 


If (isdigiKco { 

Icxdieili I i: 

} 

el.se I 

* pnntu'l d '^rr .n" ,i .( ) . * 

If lisalpIn c M { 

'■* pnnifi 'Ic.xolphiid: d '~i <) .n" A .r). * 
Ic.xalpliai c I; 

) 

else ( 

■* j^nntff "Ir\\wjti hd~f d t * 

Icxswin Inc 1, 

) 

I 

pr n - ' : d ' . ti .1, kt t: ! 1 d J \ pt .h dtn !■ -k ■. * 

return' lokcn ' 


//,'/ r jii' I'r ■' '. 1 .' ' '■' //;■ p'f'C'ti'N III-)] Utni li'-r t: entirled 
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I* to correspond to the BNF name oj the Pascal Construct which it handles * /i 


/* a/icr called must get next token * / 

prograni_heading() { prOgf'Qfn_h€Clding 

If (Itokflag) 

token = lex(); 

If (tokflag) 

tokflag = FALSE; 

If (token.toktype = _ident) { 

SC++; 

strcpy(stnck[sc],tok, token.lok); 
tc*cn = lext); 

If (token.’.oktype == _leftpai) { 
toker = lex(); 

If (token.toktype == _ident) { 
token = lex(); 

while (token.toktype = comma) ( 
token = lex(): 

if (token.toktype = _ideiit) 
token = lexO; 

) 

If (token.toktype = _rightpar) { 
token = lex(): 

If (token.toktype = _semicol) 

return: 
else return: 

} 

else return: 

) 

else return: 

} 

else return. 

) 

else return: 

} 


:* after called must gel neM token * 

lal'el_dei._j'art( i { label_dcc_part 

If (!t<'kflaEi 

token = Ic.xi ): 

If (tokflagI 

tokflag = FALSE 
If (token.toktype == inti { 
token = IcM ): 

while (token toktvpc != senneol) ( 
token = le.\(): 

If (token.toktype =- _inl» 
token =lc.x(): 

else return: 

> 

return: 

> 

else return: 


eonstann I { COUStaUt 

If u token lokivpe — inC H (token.lokivpe - realu 

return 

else If (I token lokt\ [x.- -- plnsi II I token.toktype == mimisii { 
token ■ le.\i I 

If 11 token tokt\pe mti It (token (oklv|’e = = tcalo 

reliini 

) 
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else If (token.loktype = _ident) 

retarn: 

else if ((token.toktype == _plus) II (token.lokt^-pe = _minus)) ( 
l</ken = lex(); 

If (token.lokl)pe = ident) 

return: 


} 

else If (token.toktype = _slring) 

return: 


else 


return: 


) 

/* (iftcr called must get next token * / 
con.st_dcf() { 

If (token.toktj'pe == _ident) 
token = lex(): 

else return: 

If (token.tokttpe — relational opt 
token = lc.\l): 

else return: 


constant( i: 

} 


'* sets tokflag hefoie terminates * 
ton^l dcf paiK) { 

!?(Itokllag), 

token = lex(): 

Ifttokflag I 

tokllag = FALSE: 
eonsl_((cfl i: 
t<iken = le\(): 

while (token.toktype == _setnieoh { 
token = lex' i: 

ifttokcn.toktype == _idenl) { 
tonsl_def( i: 
token = lcx( i: 

> 

else { 

tokflag = TRl'E: 

return. 

) 

) 

) 


type definition parti i { tXpC 

Ifl llokHag' 

token - lexi i: 

Ifilokflag I 

Inkflag =. FAI SF. 
lypc delinilion' ' 

If iMoknagli 

token - lexil, 

tokiiagd = false;: 

* detimuon :>l\ju'->St'ui lii^ cd t\pt * 

■* u'lj'.hktil st'iclii" s\pt~ sc: t\pi - ' ” 

* siinrli l\j\ (.uo./d /i/'( ect' nest teke'u * 

while (lokcii loklx pc ■ icniii.oli { 
token - Ic'.i •; 

If I lokcn.tokt’.'pc - - idcnl 1 { 
l\ pc delinilioni 


const_def 


constjdcfjyarr 


definition jiart 
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If (!tokilag4> 
token =lcx(); 

If (tokflag4) 

tokflag4 = FALSE; 

) 

else { 

tokflag = TRUE; 

return: 

) 

) 

} 

type definitiono { typejicfifiition 

If (token.loklype == _ident) { 
token = le.K(); 

If (token.toktyjie = _relational_op) { 
token = lex(); 
type(); 

) 

return: 

) 

return; 

) 

f!calar_typc() { SCQIqV tXpC 

If (token.tokt\pe == _idenl) { 
token = lex(l. 

If (token.toktype == _coninia) { 

while (token.toktype != _nghtpar) { 
token = Icxd; 

> 

token - le.xt); 

return: 

) 

return. 

> 

return. 

) 

■iiihiiuige i)pc(i { sufyi'cin^c 

con"^tanti i: 
token = lex' i. 

If (token.toktxpe == dotdoli { 
token = lex( I. 
constanK i. 

) 

> 


simple type! I { siniplc tVlH’ 

If (token toktvpe =- Icltpai i ( 
token - Icx' .: 
staint I\p' ' 
tokll.iBl - IKl'E: 

) 

else If (token loklvpe -- nieni ^ ( 
token - lex' e 
If (token loktspe -- 

token = lex' 

t onsiimn I. 

token -lex' ' 

loknapl = TKIT 


liotllol I { 






else 

loknag4 = TRL^E; 

) 

else if ((token.toktypc == _int) II (token.toktype == _real) II (token.toktype =_minus) II (token.toktype == _plus) II (token.toklype 
subrange_type(): 
token = lex(); 
tokfIag4 = TRUE; 

) 

) 

unpackcd_structured_type() { Ulipuckcd StfUCtUfcd txpc 

If (token.toktype = _aiTay) 
arraytypeO: 

else If (token.toktype — _record) 
record typet); 

else If (token.toktype = _s“ti 
.>!et_type( I; 

else If (token toktype = file) 
file type! 1; 

else return; 


typeo { type 

♦ siniplr_t\pc < hc( ks to see if the token toktype is Jlefipjr first * / 
if ((token.toktype 1= _pointcr) (token.toktype != _packed) && (token.toktype != aiiayi && (token,tt>ktype != record' && II 
siniple type! ); 

If ((token.toktype == _packcd) II I token.toktype — _aiTay) II (token.toktype == _recordi II (token.toktype == _seti II (token.toktype 
stfuctuied_tvpc( ), 

) 

if (token.toktype == _poinleri 
poinle!_type(); 


array_typc( I | UllXlX txpv 

token = lex' i; 

If (token.toktype == _leftbrace) { 
token =leM i; 

while (token.toktype != _ripblbracc» 
token = le.x(;; 
token = le\( l; 

If (token toktype == _ofi { 
token = lex( i; 
type' i; 

> 

I 

> 


^ilnin. lured lypc( ' { 

tinpa'.kcil .sliui.luted t(jx'l). 

If (token,toktype =- packedt { 
token = lc\t ); 
iinpat kcil ^■l^uctllred_t^pe( > 

) 

) 

ic'.otd lypol' ( n/’( 

If I'lokthii'. 

|Mk..|, - |,.v. ; 

lokH:.)- r.ALSk, 


styuetiiiedjtxpe 
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fieM_lisl(); 

If uoken.toktjpe =-- _end) { 
token = lex(): 
tokilag4 = TRUE; 

) 

) 

ficid bsio { fieldJist 

If (token.tokl\pe == _ta.se) { 
variant_part(): 

return; 

} 

else If (token.toktj'pe = ident) { 
fixed_part(); 

If (token.toktypc = _casc) 
vanant_part(); 

else return; /* token iokt\pc == _cnd *! 

} 

else return; 

} 

fixcd_p:irti) { fixed_part 

record sec tion'); 

If ( 'lokflag4) { 
token = lex'); 

* recDiil sc( li(’n->r\pc->!lructiticd rvpe-> * 

* iin/uii ked ^Inirtii'f t\pc—':>if set type —■> ♦ 

simpleJ\pe isiinplr type ^eiy ncM token! ♦ ■ 

} 

I,,kni.g4 = FAL.SE: 
while (token,l<ikl\pe == seinicoli { 
token = lc\( i; 

If ((token,loklype _end) eStet); (toketi.toktype != case.','{ 

record seetton't; 

If (Itokilng-l) 

token = lex( i; 
tokflagd = FALSE; 

) 

else return: 

} 

} 


lecoid section'> { VCCOl'd SCCtlOll 

If (token toktype =- ident i { 
token - lesi i. 

while ( token,lok.lvpe =- coninial { 
token =■_ Icx' I, 

If ( token,toktype = ident' 
token = le\i i, 

I 

If ( token (ot.i cp... etdon' ( 

|oketi r lex' 1, 
type' ', 

) 

) 

I 


c.uninl p.iiti ' { 


vanumjnirr 








token = lexO; 

If (token.lokt)'pe = ident) { 
token = lex((; 

/* l ig field * i 

If (token.toktype == _colon) { 
token = text): 

If (token.toktype == _ident) { 
token = lex(): 

If (token .toktype = of) { 
token = Iex(); 
variantO; 
token = lex(): 

while (token.toktype == semicol) | 
token = text); 

If (token.toktype = _end) { 

return; 

} 

variant)); 
token = lex(); 

) 

lokflag = TKl^; 


else If (token.ti'ktype == _of) { 
lokcii = le\>); 
vaniuiK I. 
token = le,x(): 

while (token lokui’e == scinieoli { 
token = lex( i; 

If (token.toktype == _end) { 

return, 

I 

else { 

vananK ); 
token = lcx( i; 

) 

} 

lokflac TRUE; 

return. 


vmianK i { 


vanant 


t a'^e label li'id i; 

If (token.toktype —= eidoni ( 
token = lexi ): 

If (token toktype ^leftpat ' { 
token - lex' i. 
field lien 1. 

If (token.loktv|x- == riglitpai i 

return. 


■■! t\|'''‘ ■ 1 

If I 'Inktlart 

to).eli - lex- 


SClJXJH- 













if (tokilagi 

tokflag = FALSE; 
if (token.loktype = of) { 
loken = lexO; 
simpletvpeO: 

) 

} 


file typeo { file type 

iJF (hokflag) 

token = tex(); 
if (tokflag) 

tokflag = FALSE; 
if (token.loktype = _of) { 
token = lex(); 
typeO; 

) 

) 


pointer type)) { pointer_type 

if (token.lokt>-pc == _pointer) 
token = !ex(); 

if (token.lokt\'pc == idem) { 
token = lex)); 
tokilagd = TRUE; 

> 

) 


variabie_deeiaratinn_part() { vaviablc_declavat}0)1 _part 

token = lext): 
variable (icelaraliont i; 
whllettoken.loklype == _>!eniicol) { 
token = lext); 

If (token tokt)i'c = _idenli 
variable dei. larationl); 
eise { I* must icturn ic main * 

tokflag = TRUE; 

return; 

) 

I 

. ■* yanablc jicilai auon J\pc->sliuctuicil _t\ec->unpai.-i<cd slim lure l\pe-> ’/ 

If SCI_l\pc->simple type (simple type cels nc\l loAeni ♦/ 

) 


variable declaration!) { YGrioblc_(i€ClorQtJOtl 

if (loken.toktN-j-'C -- ident) { 
token = lext >. 

while Itoken.tokt\7ie == coininai { 
token = lexi ). 

If (token.tokti-['e == ident i 
token - le\i i. 

> 

If I token toki vpe == colon i { 
token -lexi i. 
tvf'et I. 

) 

toknael ^ TRUE; 

) 

I 
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prwedurt headingu { pi ocedui e Heading 

If (!l<'kflngl 

token = lex(K 
If (tokflag) 

tokilag = FALSE; 

If (token.toktype = _ident) { 

SC++; 

strcpy (stacklscj.tok.token.tok): 
token = lexO; 

If (token.toktype == _semii.ol) 

retoro; 

/♦ return to calling junction * / 
else If (token.toktype = _leftparl { 
f orm al_paraniete rsect ion(): 
while (token.toktype == semicol) { 
formal_pararneter_section(); 

) 

If (token.toktype — rightpar) 
token = lex(i; 

If (token lokfype == semicol) 

return: 

) 

) 

> 


* formal_paianiclci section gets next token * . 

fonnal_paranictei_scclion() { fomial_paranU’tCI' SCCtlOH 

token = lex' I; ~ 

If (token.toktype == _i(lent) 
parameter group' ); 

* ttets neit token * 

else If (token.toklype == vai i { 
token - Ie,x( i: 

, irametei groupt); 

•* gets nest token * 

) 

else If (token.toktype -- _func(ion) { 
token = lex( ); 
paranietei group' i; 

* gets next tokcr: * 

) 

else If Ooken (oktype == procedure' { 
token = lexi); 

If (token loktype == identi { 
token = lex( ); 

while (token.toktype == comma) { 
token = le.x(). 

If (token.toktype == ident) 
t<(kcn = lex) i; 

) 

* uhen tirushcJ gets nest token - nghti'ar or semicol * 

> 

) 

I 


* C'!'. nio: token coin' o senn, o', ot nglitj\t> 

I'.ir iinelei gfonp' i { ptiI'lllllC!CI gl'tUip 


If ' loken ("kl \ pc -- ntenl ' { 
("ken - IcX' I, 
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while (token.toktype == _comma) { 
token = lex(); 

If (token.toktype = _iclent) 
token = lexO; 

) 

If (token.toktype == _colon) { 
token = lexO: 

If (token.toktype = _ident) 
token = lex(); 

) 

} 

return: 

) 

function headingO { futlCtion 

If (Itokflag) 

token = lex(); 

If (tokflag) 

tokflag = FALSE: 

If (token.toktjpe == ideni I { 

St ++: 

stR'py(stack[sc |.tok,token.tok), 
token = text): 

If (token.toktype’ == _coloni { 
token = lcx(»: 

If (token.tokrtpe == _ident) ( 
token = lex(!: 

If (token.toktype == seniicol) { 
token ■= lext I: 
tokJlag = TRLT: 

return: 

) 

) 

return: 

) 

else { 

If (token toktype = leftpari { 
formaI_parantete!_section( I: 

while (token.toktype == semicol) | 
token = lext i, 
fomial_paraine(ei_section( I: 

) 

If (token toktvpe == _nghtpai) { 
token = lext i: 

If (token.toktype == colon) { 
token = lext i: 

If (token.toktype == ident) { 
token = lext): 

If (token.toktype = _seniico|) { 
token = lex (): 
tokfl.ag = TRUE: 

return: 

} 

) 

) 

> 

) 

) 

> 

) 
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/* <unlabelleJ sluienu'n!> or <lahet\ <unlahe!led ilalemenO */ 

siatemenK I ( StQt6T)l€1'lt 

lokflag = FALSE; 

tokilagl=tokflag2=toknag3=lokflag4 = FALSE; 

If UoV.en.toktypc == _in\) { 
token = lex(); 

If (token.tokt\pe = colon) { 
token = lex(); 
unlabelled_statement(); 

) 

) 

unlabelledstatementt l; 

) 


'* <siniplc slalrnii'rtt> or Kstructurcd shUcmcnO * ! 
unlabclled statcmcnti i { 

If ((Uikeii toklypc == tv^gin) II (token.toktype == 
stiucluied statenienK ); 

else 

"iiniple stalenienti i; 

) 


unlahelled_statement 

if) II (token.toktype == _case) II (token.toktype = _w.'lu|e) II (token.toktype == 


'* Mmplc shilcinrnt /.t suifniicii!> oi <p>orcdurc suitfnicnt^ ot * 

'* gi'/o ilolcou'til OI cmplv HdU'iiiritl * 

siniple_?!tntenienti i { simple jitatemcnt 

Ifitoken.toktype == _identi { 
teniptok2 = token, 
token = lex( i. 
temptok ^ = token; 
tokHagl - TK'-L, 

if ((token.toktype !- assign) (token.toktype != leftbracei && (token.toktype != period) && (token.toktype 1= _pointer) 
proeedurc_s)atcntent< t; 

else 

If (token.toktype seniieoli 
assignment statement) ); 

else 

tokflag = TRUE. 

) 

else If (token.toktype == _goto) 
go to statement) i. 

else 

tokflag -- TRUE. 

) 


* \\hin \iViohlc\i IS finished eM'iitim, is scf hemusi iitnahU *' '* t>ne [fken />f\* 

vail,Lie" ( yaiiuhU 

if )mkll.nj'l 1 ( 

If ) temptok2 toktype = - _uient * { 

If oicmp(ok.ktoktvpe == leltbriKc' M Itemptok.^.toktype period) II ttemptok.',toklypc -- pointeil' { 

If )temptok.^ loktyfy pointer' { 

leniplo), t.toktype goto. 

t'd.en - lev' ■. 
tokilap - TkI L 

> 

else If ileniptoV ' ii'klype ” - leltbiaie { 
leniplok ^ lokli [’■• poll, 

tok'ni “ li-v 


7.1 




expre.s"!ion(): 

while (token.loklypc = _cominn) { 
token = lexO; 
expression!); 

) 

If (token.toktype = rightbrace; { 
token = lex! I; 
tokfliig = TRLJE; 

» 

> 

else If (temptok3 toktype == _periodi { 
teniplok.1.toktype = goto; 
token = lex!). 

If (token.toktype = ident) 
token = lexO. 
tokflag = THHE; 

) 

I 

■ *cIm: 

= THIT. *' 

while l!token.toktype “ leltbracej II !token.toktype == jperiod) II (token.toktvpe == _poin!ei)i { 
If Itokcji.toktype == poinlei) ( 
token = |ex(|. 
tok'inc - rKUE: 

> 

else If (loken,toktype =- _leltbraee) { 
token - lex! f. 
expression' i. 

while (token toktype eonini.n { 
token e lexi i: 
expression' 

} 

If Itoken toktype -- righibiaee) { 
token = lex'': 

(okliag r IklT, 

) 

) 

else If (token toktype _]>eMoil' { 
token - lextr. 

If I token toktvpe == _idenl i ( 
token = le\i i. 
lokllan =- 'no'I' 

) 

else return '•(<".■>)* . 

) 


) 

ternplokJ !okl\p'.- - goto, 
tokllinl - F.•\I..Sk 

I 

■* tot noi.'/ no /. . eii/n/oN not /n< ■* 

else { 

If ' I' nipl'd I I "1 ivp" lll'■nl' { 

If '' n-i' 'O'k'' t 'kt \ [v !e(t'''i;K I't It iteinptok S .— irenod ' '' < leniptok.Mokt\ P" - pomlei 

If I tempi ok Ink'\ IV poiiil'o ' ( 

l'•mpl''k|okt'>p’ i’o|o 

I'.ken I'o, 

I'd.lkn- - no'i 

I 

else If I Irrnp'ok'' |ok t \ p" |e||l>iaiei { 

l! ni|'lok' Iokl\p'. i:olo 

|i 'k'-n le\' ' 

( vpf" ■-lo;i' . 
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) 


while (token.loktype = _conima) { 
token = lex(lL 
expressiont); 

) 

If (token.toktype == _rightbrace) { 
token = lexO; 
tokflag = TRUE; 

) 

} 

else If (teniptok.'i.toktype = _j)eriod) { 
temptokS.toktype = _goto; 
token = lex(); 

If (token.tokrype = ident) { 
token = lex(): 
tokflag = TRUE: 

) 

) 

> 

tcmptokA.toktype = goto; 
teniplnk5.tokt\!’<■ = _goio: 

while ((token toktype == lefthr.net II (token toktype = _period) II (token.toktype = jiointeiM { 
If (token.toktype = piinter,' { 
token = lexO. 
tokflag = TRUE. 

) 

else If (token.toktype == Jeftbracei { 
token = lex( t; 
expretsiont i; 

while (token.tokivpc == _coninia! { 
token = le.xt i; 
expies'^iont). 

> 

If (token toktype == _rightbracci { 
token - le\( I. 
tokflan =■ TRUE: 

} 

> 

else If (token.toktype =- _peniHl) { 
token = le.xt i: 

If (token ((iklype — ident; { 
token - lex''. 
tokflag = TR'T; 

) 

> 

) 


else If (token toktype -- idcnt i { 
token = lexi '. 
tokllag ^ TRUE. 

while ((token toktype =- leflbr.airi II (token toktype == _pcnod i It t token,toKnype == ^poinlero { 
If (token.toktxpe =- pomtei' ( 
token - lex' . 
toktl ic - TRI'E 

) 

else If Itt'ken toktype -- Jcftbiaee' { 
token - le.x' '. 
cxprexxion' '. 

while (token tokf'pe eotnmai | 
token - lex' ' 
tokllag ~ lALSr, 
cxpie'.''‘i"n' '. 

) 

If (token lolupe -- ntrlit'MaieI 
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) 


token = lexO; 
lokflag = TRUE: 


else If (token.toktype = _pericKi) { 
token = lex(): 

If Uoken.toktype = _iden1) { 
token = lex(): 
tokflag = TRITE: 

) 

) 

> 

> 

} 

cnJ variable * 


assignment stalcmentt) { 
variabict), 

if (token lokl\pc == assign i { 
token = lex( i: 
expiessioni ): 

) 


) 


uKlexcd_variable( i { 
expression! ): 

while (ioKsn.tok(ype -= _comniai { 
token = le.xl i: 
expression! i 

> 

If iti'ken.tok(\pe =- righlbraoe i 

return. 


) 


* CI/I'C.I.W/OI jUia’.i orii' lokin he\nihl />< n/K.'t rf Mm/’le expicrsion * 
expiessioii' I { 

simple express,oiii i: 

If ((tnkeii (okf.)”-• == _relational_opl II (token.toktvpe =- _in)l { 
token = lex' i. 
simple expression! I; 

> 

toknai; = TRUE. 

) 


rela(ional opi i ( 

If 11 loken toklvpc =- in ' H i loken (''k('"p' =- relational c'p)) 

return 

> 


S III lpl»- ^ p! '• bvlf ft' • { 

if M'4 { 

If (Itcmf'tnK-l t'ikis [■''• nijrias) I' ({cni['»lok4.tf>ktv|X' == ( 

u 

while (Moken Inkiypu -- plir ' •' (token Inkfvpe == _n>j»ui'i) I 


assignment_statement 


indexed variable 


expression 


relational _(^p 


siniplc_cxprcssion 

(token.toklyjx' =- oiii { 
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) 


If (loken.loktype = _or) 
couiit++; 

token = lex(); 
temn); 

) 

) 

else ( 

terml): 

while ((token.toktype = _tninus) II (token.toktype == _plus) II (token.toktype = _or)) { 
if (token.toktype = _or) 
count++: 
token = lexO; 
temiO: 

} 

> 

tokflagZ = FALSE; 

} 

'* no! * 

else { 

If ((token tiiktype == _niinus) II (loken.loktype == _plus) II (token.toktype = _or)l { 
token = le.\( ); 
temn): 

while ((token toktype == _minusi II (token.toktype = _plus) II (token.toktype == on) { 

If (t()ken.loktype == _on 
count *■ + ; 
token = lex(); 
lenn(); 

) 

> 

else { 

tcm\( I; 

while ((token.toktype == _minus) II (token.toktype == _plusl II (token.tokt nix' == _oni ( 
If (token.toktype == _ot: 
count+ + ; 
token = le.xi): 
temii); 

> 

) 

) 


‘ live Uii’i hill hitr iiilhil riiM inkcri ,iUviiii\ nilltj * 

teinn i ( tCl'IU 

(;n. (on 

If lIlokIhiLO 

token = lexi i: 
lokflag e F'ALSF’; 

while ((token liikty(v' == multi H (token,tokly[x’ == divjilei II (token.toktype = _niod’ !■ (token.Inktvjx- == and i 
token = Icx' '. 
factoi'). 



* III: h” r ■ wvuiif'i ■ •- iiniiy’u-il lo’vhtri ' ( < ca/vf.i.w-'n.1 * 

* - Inn. 0,0: de'.rv'n..*' a ’ of <.sc'f ' (■' no: r.»f -> * 

l:i' lofi . j 

If ( (oF.en |okt\ pe - - IK'l ,1 { 

(okcii - l-xi 1 

while I (ok'-n if'F.tvpe - not f 
(okeii Icxfi, 


faciei 


I' (token.toktyi 


77 






If (token.toktype == _leftpar) { 
token = lexO: 
expressionu: 

if ttoken.toktype == _rightpar) 
token = lex(): 

} 

If (token.toktype = leftbrace) 
set(); 

if (token.toktype = _idenl) { 
func!ion_designator(); 
variahle(); 
lokflag = TRL^E: 

} 

unsigned conslant(); 

) 

else { 

if (token.toktype == _leftpai) { 
token = lexi); 
expression! I; 

If (token.loklype == nglilpm) 
token = lcx(): 

> 

If (token loklype — _leftbrace» 
sett i; 

If (token.toktype == _ident) { 
(unelion_designatoi(): 

If (token.toktype 1= scmieoli 
variable! i: 
tokibig = TRl'E; 

} 

un.signed_eonsta!it!); 

} 

) 


unsignecl_c(i!istanli! { UHSigHCd COIlStCUlt 

If (loknag2i { ' ~ 

If !!lernptok4.ti'ktype == _inll II (templok4.loklype == _rcalii 

return; 

If !!teniplok4 loklype == _stnngi II !teinptok4.loktype == _iUenli II (teniplok4 toktvpe == nilii 

return: 

> 

else { 

If !!token.toktype =- int) II (token loktypc == icalll { 
token - lex! r. 
lokllag s- TKUE; 

return; 

) 

If titokon toktype =- string! II !token loklype -- idenli II (token.toktype =- ml!' { 
token - lex! i; 
tokllag TKCE. 

return. 

> 

> 

I 


(iiiKlion ilesignaioi'' { fnnCtl< >11 di'SI I^IUI fi>r 

If 'token toktvpe == jilenl' { 

Icmptokr = token 
token : lex' i. 
leni(’lok ’ - token. 


78 
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If (token.tdctj'pe = leftpar) { 
token = lexO: 
actual paranieteiO; 
while (token.toktype = _cointna) { 
token = lex(); 
actual_paranictert); 

) 

if (token.toktype = _rightpar) 
token = lexO; 

/* to semicol recognized hv compound_statement * / 

) 

tokllagl = TRUE: 

) 

) 


sett) { set 

If (token.tokt\-pe — leftbrace) { 
token = lc.\(): 
element list(); 

Kiken = IcMi. *' 

If (token loktype == _righthrace) { 
token = lexO; 

tokflag = T7UT; 

) 

else return 

> 

I 


'* lokilai; .«•( Ii> Iikc i< niU o mulliciemcnl ctement liM *. 

clenient_list(l { clctllCUtJist 

If (token.toktype _nglitbtacei { 
clemcntt i: 

If lltokflagi 

token = lex' i; 
tokflag = F.XLSE. 

while (token toktype == commai { 
token = lext I. 
clcmenK y 
If ((tokflag> 

ti’keri = |exi 
tokflac = FAI..SF, 

1 

If I token loktype != comniai ( 

return 

) 

> 

} 


* f' .]r;> I (■ r r fu •: w.' ,f.- * 

* fit-yf fn>r. itU' ri/rKn' /,'hn * 

ck’nicnt'' ( clcfUCfl! 

If U<*kcii . p'- -- ( 

tf'kun 1(’\' 

f ^jti 7 sc, iiuU I, 

I 

lokfl.u- • TFI’F 
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pr(KC(lurc_statement() { 

If (loken.tokt)pe — _leftpar) { 
token = lex(); 

actual_paraineter(); 

Iftllokflag) 

token = lext,); 
lf(tokflag) 

tokflag = FALSE: 

while (token.toktype = comma) { 
token = lexU; 
acniaj_parameter(): 
lf(! tokflag) 

token = Iex(); 
lf( tokflag) 

tokflag = FALSE: 

} 

If (token.toktype == riglitpar) { 
token = lex(): 
tokflag = TlfflE: 


procedure _statement 


actual jiaranietcri ) { aCtUol_paratllCtCr 

* this point leftjiar has alreadx been called * 

* tcnipt(>l4 - t•■‘k^'n, 
h'ken = U'M >, 
tcfnpnd.^ r token. 

If token toktype -- Jeftbiaee) itoken ityktypc -= jyeiit\Ii ■ tlt^ken {okt\pe -=■ ^fyointei)) j 
token - le \ n. 

\ (jf lahlei ). 

» 

ebe ; 

(oktlji:: TRrr. * 

expre*isi(>(H i. 


* if fniuCiln/t hJcniifU' <'> fi4n> lion uUntifut. * 

* t<>kcn t.-k!\pt- liOnti IS hijrulieii h\ iiinahh * 


C'' 


) 


1‘• <:tatcnKii?' ■ { 

If ('lokflae' 

l‘’kcii - \c\< I 
If fldkllai:' 

i''k!i.ir - F'ALSF 
If 'If'krri idktvp'.- -- 

return 


ml' 


^_s!aiemcnt 


* I <'nip''un.: \!iiit'H!t-nt ' ft * , orhiiii'^ntj! ^hjiefncni > or *eief*etin\r statenieni 

* ’•> ' y* Ifh nu n' ' * 

^1 ! iiv lijrc'l sl.itrfn' nt { 

If M-’kcn l-'kl)!’^ tn-pii' 

k f’mp' 'iiir 1 ••l.ilrnicii! ' 

If '' l'»krn 1 '’kl\p' ifi i (t"kc-n t‘’kf \ [*• cav'H 

I fMLhli'tn.i! .fal-'fiu’ii! ' 
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If ((token.loktype = _while) II (token.toktype = _repeal) II (token.toktype = for)) 
repetitive slatement(); 

else 

If (token.toktype == with) 
with .statement)); 

) 


compound_statement)) { compound _statement 

token = lex)): 
statement) l: 

/* statement may go one token past because of simple expression * / 

If (Itokilag) 

token = lex)); 
tokflag = FALSE: 
while (token.toktype — semicol) { 
token = lex) i; 

If )token )okti.pe = end) { 
token = lex)); 
tokflag = TKL'E; 

return: 

} 

else { 

siatcmenti i; 

If titokflag) ( 

token = lex< I. 
tokflae = FAl.SE: 

> 

) 

) 

If ) token,tokttpe -- _endi { 
token = lex) 
tokOnp = TKL'E; 

return: 

) 

) 


L(mdilw'nal sialcnient' ' { COnciltK^flol StGfCniCnt 

If n<'kcii =^- if' 

il siatcriK’nl' 

else If Mi'kcn {iikivf'v -- 

I 


It si.iii nii'iiii I { if StllfCIIICIlt 

I oniii * », 

token “ lex' 
expression' ' 

If I (open I'lklvpe ' then ■ 
token lex' i. 

If I token lokt vpe ' then' { 
token - leX' ■ 
sl.ilenicn)' ' 

If Moken lokl\p'-- -= end { 

return 

I 

If iloken lokf, |i.- - else! { 
l"ken lex 


KI 


statement! 





return: 

) 

else 

return: 

} 

prinlf{"In if, count=%cf'n".count): 


case_slalenient() { CQS€ StQtCniCflt 

If (llokilag) ~ 

token = lex(): 

If (lokilag) 

lokflag = FALSE: 
expressiont): 

If (token.loktjpe == _of) { 
token = lexO: 

If ((token.toktypc — jin'!) II (token.toktype — _minus) II (token.toktypc = _mt) II (token.toktype == _string) 
case list elemeiiK ): 
count+ + : 

If (Itokflngl 

token = lex( I: 

If (tokflag) 

tokJlag = FALSE: 

while (token.toktype — _semicol) { 
token = lcx(): 
casc_list_elenient(): 
count * : 

If ('tokflagI 

token = lexO; 

If itokflac' 

lokOag = FALSE. 

) 

If I token tok(yc>e == eruli { 
token = lext i; 

lokll.ig = TKI'E: 

return 

) 

) 

else { 

If (token loktypi,- =- eml) { 
token = lex' i 
tokllaj: = TKI'E; 


(token.toktyi 


« 


la e let elenienl ' ( CilSC IlSf clcUlCUt 

t laKcl lot' i 
If I li ikeii |oki \ (V - t o|on I ( 
lok-n - lex' ' 

If 'loV.c t to<1 vpe -- xeniixol' 

return 

else 

•it.itenienli 

I 

) 


xa'.e l.tlxl h'.t ' ( 


case label list 
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ccMisiiinU): 
token = lexU; 

while (token.toktype = comma) { 
token = lext); 

constant)); 
token = lex(): 

) 

return; 

} 


rcpetitive_statenjent() { VCpCtitlX'C St(lt6fTl€Ht 

if (lokcn.tokt\ 7 ie — _while) 
whilestntemcnto; 

If (token.toktvpe = _repeat i 
repeat statement)); 

If (token t<ikt\pc == for) 
for stalement)): 
return: 

) 


while slatemento { WkUc_StatemeUt 

counl++; 

If (Itokflagl 

token = Ic.xt): 

If (tokflapi 

tokflai: = FAL.SE; 
expression' i; 

If (token.tokijpc == _do) { 
token = lexi i. 
statement) l; 

) 

> 


repeal sialementi i { I'CpCUt StGt€f7]t'1]t 

count * *. 
token - lexi i. 
si.aienteni' i; 

If (!loktlai;i 

token - lex't. 
lokflap = FALSE. 

while I token.toktype =- senncoli { 
token - lexi I. 
stalernent' ' 

If t'lokflayo 

token - lexi i. 

If ilokllaci 

tokHae FALSE 

) 

If lloken lokly]'>e -- until' { 
token - lex' 
expie-'-ioM i 

I 

return 

I 


|oi aaienienl 


for .Miircmcnf 
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counl++: 
token = lexO; 

If (token.toktype == _tdent) { 
token = text): 

If (token.toktype == assign) { 
token = lexi); 
for_list(); 

If (token.toktype == _clo) { 
token = lex(); 
stnteniento; 

return: 


} 

> 

} 

) 

for listi I { foi list 

expressiont): 

If ((token.toktype == _to) II (token.toktype == _<lottnto)) { 
token = le.\(); 
expression!); 

> 

tokllag = TKL'E; 

return: 

) 


with_statcn)enl( ) { W'ltll _ StUtt^niCHf 

If (Itokflagi 

token = lex(): 

If (tokflag) 

tokflag = FALSE: 
rceord variable lisd (: 

If (token.toktspe == _clo) { 
token = lex(): 
statemend i: 

> 

) 


rcc('ul variable livd i { TCCOl ii VCH'ldhlc IlSt 

variablei i; 

If (Itokflag) 

token = lex(i: 
tokflag = FALSE; 

while (token.toktvpe eonimai { 

If (Itokflagi ' 

token = lex( ). 
tokflag = FALSE, 
variable! i. 

> 

> 


maim i { fthlll! 

Ini viaitline. 
liMcronnl. 

while'Meo((siilin o { 

Ifl'toklla;'. 

token = leM i. 
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Ifltokflag) 

tokflag = FALSE; 
if (token.toktype = _program) 
program_heatling( l; 
else If (tokcn.toklype = _label) 

Iabel_(iec_par1(); 

else If (token.toktype = _type) 
type definition_part(); 
else If (tokcn.toktype = _coiist) 
con.<!t_def_part(); 

else If (tokcn.toktype = _packed){ 
printfC'Have patkeiLji"); 
structured_typc;); 

} 

else if (tokcn.toktype == _array){ 
printf("Havc arniy''o"): 
arrav_type(); 

} 

else If (tokcn.toktype —_recordl{ 
pnnlf(’Have recorcf\ii'); 
reeord_tvpe(); 

> 

else If (token toktyiK == case){ 
pmitfi 'Have c'ase'\n "j; 
case statcmcnt(); 

) 

else If (token.toktype == _set){ 
piintf("Have .set'\ji '' 
set_tvpc( I: 

} 

else If (token toktype == 
pri(ttf("Have file'jt"). 
file_tvpci i; 

} 

else If (token.toktyi'e == _van 
vanahle_dcclaration_pai1( i, 
else If (token.toktyfx- == _pr(Kediirel 
proccdurc_ltcai.ling't: 
else If (tokcn.toktype == _hinctioni 
function_heading( I; 
else If (token.toktvpe == begini ( 
slanliitc = line; 
count - (t; 

compound siatementt); 

If (sc >= 0i { 

linecounl - line — st;utluie; 

prinifi s: e, d ‘o dji". stacklsc).tok.coun(+1 .lincconnt 

sc -= 1; 

) 

} 

else If ' token loktvix- -i* if'{ 
piititfi "Ha\e ifai 'i. 
il siatemeiiK !. 

I 

else If (token toktype -= «liilei{ 
printft "Have wIuIcmi I; 
wliilr statement', ], 

) 

else If I token li>ktv[>e -- lepeatd 
piiiitl'' Hn\e rcj'cat ji' 
lepcal statcmcnli ), 

) 

else If (token.toktvp' =- lot i| 
piint It "11.0 e l('t ji I. 
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for_slatenicnt(); 

} 

else if (token.toktyne == _with) { 
priiilf("Have withXn"); 
wiih_statement(); 

} 

else If (token.toktype = _pointer) { 
printfl Have pointerVi"); 
pointer_t\pe(); 

} 

else If (token.toktype = _goto) 
go_to_staIement(); 

) 

> 
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